Components and mapping solutions
Estimated duration : 15 minutes
App Inventor lets us go mobile AND enables to build “location aware” Apps which can display and interact with our spatial environment : build games like Pokemon Go or services like pizza delivery management or manage a fleet of vehicles like Uber.
These apps will generally require 3 kinds of services :
- Mapping (with Open streetMap, google Maps or other services),
- Geolocation, indoors or outdoors with GPS, network, SSID, IP, …
- Data sharing on the web with structured databases (cars, customers, pokemons, …)
This tutorial, deals with the first subject : mapping
(we look at other ones in other tutorials : see the Geolocation and database tutorials).
App Inventor offers many different ways to do mapping with very different capabilities. We will see 5 of them :
- Mapping with a "web viewer" component and Open street Map or Google maps services,
- Mapping with the "Start Activity" component and the Google maps App,
- Mapping with a "Canvas" component with the "static maps" and "streetview"APIs,
- Mapping with the new "Map components" and the open street maps server,
- Mapping with a "Web viewer" component and "fusion tables" to share, display and manage data on the web,
These five techniques enable VERY different App capabilities :
- Mapping with a Webviewer and WebMap Services is quick and simple.
It provides good Map display with dynamic web interaction, but has poor capabilities to incorporate user’s data and does not allow feedback from the map back to the App.
- Mapping with the Start Activity has similar capabilities and limitations.
It offers more display options, and has a well-documented API (Application Programming Interface). However, your own App disappears while the map display activity runs (and comes back when you quit display). This solution is strongly connected to the Android "Activity life cycle" which is a little too hard to explain here, so that you may use concepts which you may not quite understand.
Above solutions are fine if your requirement is to use map display for interactive output only display (of directions, locations, …) with limited user data. This is often the case, and you will find nice and popular Apps in the gallery, such as “find my car” that use these techniques.
Solutions below enable two-way interactions between maps and App data. These interactions are key for games where you handle “actions” in the map (like Pokemons) or for business App that interact with fleets of vehicles (like UBER or pizza deliveries).
- Mapping with a Canvas and static APIs :
The choice here is to keep full control inside the App, and manage all interactions within the canvas component which also holds sprites and balls. In this case, maps are handled as image files. Interactions are unlimited but you have to write code for each one : this powerful solution comes "naked". However, we will provide reusable code to help (ex : translate pixel coordinates to geographic coordinates, measure distances in km, zoom, pan, etc.) but still, you will have more work to do than with solutions 1 and 2. This solution is fit for Pokemon like games, or when you need two-way interactions between App and map.
This solution has very nice extensions such as streetview, for walking in the streets and 360° views inside buildings. This can be great for “treasure finding” games (but requires some maths ...). - Mapping with (new) App Inventor Map components :
The choice here is intermediate. These components provide nice map handling that will enable fast development.
With regards to the canvas solution, you gain native event capabilities and you loose real time animation and interaction with sprites and balls
With regards to the "Webviewer" and "start activity" solutions, you gain 2 way interactions and you loose server level functions such as itinerary, 3D views, ... - Mapping with fusion tables and a webviewer :
Fusion tables have nice mapping capabilities. They also enable management and sharing of data on the Cloud, for multiple players. They come with powerful query capabilities (SQL like), that are necessary to handle interconnected data (ex : customers, orders, fleet of vehicles, deliveries, …).Note :
The choice here is to make FULL use of cloud services to manage BOTH data AND maps!
Use of a webviewer first implies one way interaction and loss of control on map events...
BUT the magic is that "fusion tables" servers have their own handlers, and send back some control to the App, through data management service APIs. Map AND data management are both subcontracted to cloud service. Most of the job is done on the Web (outside App Inventor) but you STILL have control from inside your App! This is great for sharing large datasets with geolocation on the Web. Go ahead and start your UBER company.
As you may start to see, there is no good or bad solution. Your choice will depend on your needs. "Pokemon like" Apps and "Uber like Apps" will have opposite criteria. We will come back to this as we go.
Besides this "architectural" side of things, we will also have to consider dependencies on services that we use :
- Is it the same to use Open street maps, USGS, IGN, or Google services ?
- What will they know about App users' activities ?
- Do you have privacy issues ?
- ...